home *** CD-ROM | disk | FTP | other *** search
Text File | 1993-12-20 | 41.9 KB | 995 lines | [TEXT/MPS ] |
- PROJECT IDEAS
-
- --GDL
-
- Define a global "side*" that is a list of all sides.
-
- In evals, do binding of "this" so expressions like (count <u> (this side))
- work.
-
- Could restrict some tables to 15 bit integers, use top bit to repn varying
- value, up to 16d15+127 by doing a 4/4/7 split of bits.
-
- Support full decimals for parms, flush the "10000" numbers and add scale
- factor to all numeric parms. Scaling fixed by code, use scaling when
- computing effects.
- Ambiguity if context of decimal doesn't include scale factor (as in "define"),
- but could support decimals as a distinct type in GDL (as ratios instead of
- floats?). c_number should convert to integer, or check validity of uses.
-
- Be able to mix .imf and .g files/forms, scan all .g files to collect
- images (but possible name conflicts...)
-
- Add conditional loading via (if <xxx>) and (end-if <xxx>) forms.
- Syntax inside must be correct, unlike #| |#, but forms only read
- if disabled, symbols not interned or strings allocated.
-
- Add an (x (disappear ...)) extension is that like appear, but
- schedules unit to vanish at the end of the given turn.
-
- --Types and Objects
-
- Clarify vision rules. The true state of the world is a set of layers.
- For each cell in each layer, there is an apparent value, a date for
- that value, possibly prev values also. Only need bit if value always
- accurately known once discovered. Elevations and features unlikely
- to change, but weather, units, people, material often inaccurate.
-
- Storms are considered to be very-high-density cloud.
-
- Impl constant elevations and temps that don't need a whole layer (how
- to recognize?)
-
- Allow some moves to use random mp, be able to specify +/- amounts.
- This is mp (and acp?) consumption only, does not affect validity of action.
- ut_mp_extra?
-
- Define a notion of hp for bord/conn types, allows for interdiction
- and repair.
-
- Side library should be able to allow multiple usages of some members.
-
- Define a hallucination chance for some utypes:
- (sp-)looks-like u1 u2 -> n% is chance that u1 appears to be a u2
- and is recorded as such in a view.
- Note that code should ensure that only info about image is displayed
- rather than hallucination.
-
- Use a slot (which?) to indicate variation radius of actual reinforcement
- position around given xy. Default of zero requires to be on actual xy.
-
- Implement ZOC as a layer for ZOC ranges > 1.
-
- Add a new layer coveralt to indicate the lowest altitude visible
- to any unit on the side. Adjust along with basic coverage.
-
- Add a "facing" bitmask that indicates the directions that a unit is
- "facing", or can operate in, add effects of facing vs non-facing.
- Come up with a display for this.
-
- Events can have causes that they should be tied to, can use to
- enhance displays etc.
-
- Write out a side symbol (if defined) for unit sides.
-
- Add a (x (symbol <sym>)) to units that can be used to write a symbolic
- ref to unit when saving.
-
- Maintain an in-supply bit for units.
-
- Add a way to make incomplete units age and eventually vanish
- (cp-attrition?)
-
- --Setup
-
- Set growth algorithm so that growth always makes area known, if not
- actually expanded into.
-
- Add a "spur" phase to road gen that connects to nearest road.
-
- Add a chance for roads that just cross the area from one edge to
- another.
-
- If a next dir for a road has a possibility to connect to a unit
- of a type that roads connect to, choose the dir to that unit over
- any open terrain direction.
-
- Player mix test should be allowable_player_mix(assignmentindex),
- allows "scapegoating" a particular player if failed - gives
- a starting place for interface to fix.
-
- Define parms for variability of initial materials using variation
- on fractal percentile synth method.
-
- When using area restriction, need to be able to support both local
- and global coords of units being read in.
-
- Change random renaming to offer a list of choices, but not to load
- all the emblems.
-
- Liquid adjacent terrain types should always even out to same elevation
- (highest of all the competing elevations?)
- Flooding is always instantaneous if ttypes changed by a unit.
- Non-liquid border might or might not be a dike.
-
- For unbalanced scenarios, provide a way for designer to indicate
- estimate of relative strengths.
-
- Write interpretation of player-mix expressions.
- For now, just do <>= on player "templates", and boolean combos.
- (extend to side classes or even player/side assignments?)
-
- Add density of occupants of indep units already placed. Specify for
- both units that have to be occs and others that don't.
-
- Need a way to coordinate all name gen for a single side -
- "foo" -> Fooland, Fooard, Fooards, Fooish" Could also decide colors and
- emblem randomly, but wouldn't need to coordinate.
- Specify just *one* side name generator, extensions added in a standard
- way by an nlang.c routine.
- Predefine nonterminals side-name, side-noun, etc in side-namer grammar.
-
- Add "earthlike" generator that borrows code, but is completely wired
- to do Earthlike stuff, including a semi-wired set of terrain types
- (use extensions to recognize by attributes rather than position,
- so that river deltas can be flat and swampy indep of how terrain type
- fits with others in a game design).
- Use tectonic code at some scales, erosion at others.
- Could base calcs on sphere, translate to world grid when done.
- Base on all real dimensions, so alt ranges wired.
- Parameters are area size/world.circumference for the scale
- (assume 100 km/cell if weird circumference),
- latitude of area, range of elevations (0 - 10000 meters),
- distance from coast (at center of area, allows specifying distance such that
- area can be 3/4 land, etc), average temp, average rainfall.
- For tectonics, use layers for plate num, move dir, and elevation.
- For small-scale, make random ridge/high point, erode down to lowest
- or to coast.
-
- Could add recorded events that get played when their scheduled time
- arrives, so that a city could revolt or disappear at a preset time.
- Playing scheduled events should happen after acp/mp calc, but before
- players actually get to move.
-
- Kernel should be able to do a system reset - all data structures
- and all allocation, so that a different game can be started up.
-
- Add synth method for secret scorekeeper goals.
-
- Use password to match up players when restoring into a different set
- of displays. If no password, then will just accept a different
- assignment, perhaps warn for cmdline setup, flag in dialog boxes.
-
- Any terrain-based variation, such as temperature, should check
- if need to represent varying values over area, don't need to
- alloc layer if not, *but* may need to quickly synth layer if
- terrain is added that *does* allow variations.
-
- --Plans and Tasks
-
- Still need way to set when unit can be run by side, and when it makes
- own decisions.
- Doctrine can set probability that unit will ask for
- orders when (a) all of its tasks are completed, (b) it decides to replan
- (decision interval is up to unit), and/or (c) something unusual happens
- and plan sounds an alarm. Range of probs defined by game, so some units
- are never better than 50% to ask what to do. Units acting on own use
- neither AI or player, but have a separate algorithm (same as the "no brains"
- AI algorithm - still executes from plan, but bypasses AI hooks)
- Uncontrolled units can be given orders, but have some chance of changing
- the plans arbitrarily. Min/max of chance set by game, doctrine can set
- within those limits.
- "Control coverage" sets where units can be controlled, where act on own.
- Need some sort of event to notify when unit is in control range.
- Note that some units might be controlled by several sides at once.
- Lack of control means that units can be given plans and tasks,
- but will not always carry out the appropriate actions (could fail to
- act, or subst other actions)
-
- "Intercept/defensive" plan directs units to patrol in an area, attacks any
- enemy unit (doctrine defines "enemy") that is of a type that can be
- attacked/harassed/blocked (ignore types that we can't do anything about!)
- Only some kinds of defensive units are interceptors, others are blockers
- or kept in reserve. Blockers interpose rather than attack enemies,
- while reserves avoid contact until plan is changed. Defn of "reserve"
- partly depends on attacker, so fighters intercept bombers but ignore
- battleships.
- Do as explicit decision in general defense plan.
-
- Re-evaluate return if transport moving away too fast.
- Could have a "home" unit that is preferred if in range, such as
- fighters assigned to carriers. Don't return to transports that
- don't have any fuel, unless there is no other choice. Special-case
- grounding of aircraft if no supply in a base vs starvation of troops
- if no food in a base.
-
- Exploration plan should set recon vs invasion type, use to decide
- about visibility while exploring. Recon should attempt to gather
- knowledge without being seen.
-
- If can refuel along a route if chosen correctly, subdivide move task
- so as to stop at refuel points.
-
- Define a plan type that tracks/shadows units while staying out of sight
- as much as possible. Would have to keep unit within view range but outside
- of its view range (and any other coverage, should write something to see
- whether a given cell might be visible to enemy), but may have to get
- closer to avoid losing trackee. If unit being tracked seems about to
- do some damage, engage instead of shadowing. May sometimes want to
- move to block or slow down trackee's escape.
-
- Need special scenarios to be able to test all plan types accurately,
- should set up similar tests for all major parts of planning and AI code,
- each should ensure that all the code bits actually get executed.
-
- Plans that fail to decide what to do are a potential problem, should
- eventually be replaced, but not too often or else warn about replacement.
- Track total usages as well as per-turn usage.
- Each successive plan for a unit should have a distinct serial number,
- display when displaying plan. (units never share plans)
-
- All units should get a chance to replan after acp/mp calculated
- but before anybody moves. Should be fast, since nobody can move
- while this is happening.
- (Interface should be more obvious about this, so less confusion
- about turn change.)
- Give human players a chance to review plans made by high-initiative units
- before irreversibly made (flag review-plans, shows plans of units that
- are selected).
-
- What about a task to not just resupply but to prepare for a long trip?
- Stock enough to make a crossing, etc.
- Check when doing an approach task, may want to push a "fillup" task.
-
- Add notion of "supporting" another unit to doctrine, then unit could wake
- up and get involved automatically if combat nearby.
- Should specify by type & distance, as well as particular unit.
-
- Do general org chart mechanism.
- Allow promoting any (or restricted type?) unit to be a commander, and
- assignment of units to commanders. Cmdrs always move before other units,
- units can have orders to follow cmdr, cmdrs could have utype requisitions
- so production automatically goes to them.
- (Machine player could use this too.)
- Add a display to show how everything relates.
- Define a commander_decide_plan(cmdr, unit) or have cmdr make tasks directly?
- Each commander should have (or appoint) a deputy unit that will get its
- plan data if it dies. If deputy dies, should work down through orgchart
- to find anyone, only giving up if entire group is gone.
- "Commander" plan is mod of other plan types, cmdr bit is for coordination.
- Cmdr plan includes an "ideal" mix of types to command.
- AI uses to set production, human gets told of cmdr unit's needs somehow.
-
- If no AI or display on a side, what should units do?
- Will still have doctrine, attitudes, loyalties, so plenty to work from
- (include indepside in this but have no side-style coordination?)
- Can have and execute plans but no mechanism to change plans
- (i.e. can be read in but not altered thereafter - would need to flag?)
-
- Should be able to set a "build rate" that is slower than "fast as possible",
- to avoid material depletion. (i.e. use doctrine to set default rate of
- build actions, set actual rate in build task?)
- Define as amt of time to wait before starting build of next type (if the same).
-
- --Actions
-
- Add a separate chance for defender to capture attacker upon counterattack.
-
- Add a material cost um_material_per_<type> and prerequisite
- um_material_to_<xxx> for all actions.
-
- When "firing" aircraft from airbase, should recover most and lose a few.
- Generalized notion of fire interdiction would be useful, could subsume
- effects of jammers and suchlike.
-
- To do < 1 cell/turn speeds, available acp should translate to
- occasional ability to move.
-
- Some types of combat should not be able to reduce victim hp below a given
- level. uu_min_hp_from_hit.
-
- Define material-theft-per-contact(u1, u2, r) -> n in combat,
- material-loss-per-hit(u1, u2, r) -> n which is material completely lost.
- Some could be "resorbed" by terrain?
-
- Some occ types should be able to prevent capture entirely, others don't,
- are just captured or destroyed themselves.
-
- Some occ types could protect by intensifying counterattack.
-
- Chance to surrender should be higher if damaged.
-
- Occupants of captured units might get to stay if friendliness-to-enter
- allows it (?).
-
- Detonation's effects should depend on altitude of detonating unit -
- compute the "actual" 3d distance.
-
- Damage to multi-part units could be done by detaching wrecked-type
- instead of damaging all parts equally. Do only if wrecked-type
- has appropriate sizes. Only applies if wrecked-type has equal num
- parts to original type.
-
- Could do multi-cell move actions as repn of hex entry until
- anything happens that requires a decision - blockage, etc.
- example: acp = 1, mp/acp = 10, allows single move of up to 10 hexes.
-
- If a side wins a battle, then side's units involved should gain affinity
- for side, lose fear of other side.
- On losing side, units lose affinity for own side and increase fear of
- winning side. Nonparticipants also affected, but less so.
- Affinity increases by positive acts, fear increases by negative acts.
- Betrayals should be detectable, have large effect.
- Need some implicit agreements about defense of units on a side,
- that players should not violate.
-
- Side action limit should be a distinct value, decremented only for "manual"
- activity by player (first action after waiting for input?).
-
- --Backdrop
-
- Add ut_people_supply that is amount of supply gotten by unit if people in
- cell are on the same side.
-
- Express need for limited supply as "n turns of supply before starvation"?
- Can lead to tough decisions about starving rear areas for sake of major
- offensives, etc.
-
- in-length > 0 + ability to transfer from terrain means unit
- can get supply from cells other than own cell.
-
- Should choose side to revolt to by counting
- number of units (of same type on each side?).
-
- Siege surrender chance should be distinct from normal surrender chance.
-
- [need to identify motives for demand, if rtype not needed
- for actual survival - dyes needed for "art" for example -
- might vary between sides/unit types?]
- [would need to define generic elasticity of demands,
- also the profit-seekingness of a population (vs conservatism, etc)]
- [can designate a material type as "money", so is used in exchange]
- [need some notion of credit too?]
- [units can effectively forage at some distance, distinguish foraging
- from actual production]
- [price should go up as material is transported further and further,
- and across varying difficulty of terrain...]
- [note that as sides, players can't force cell economy but can
- encourage it]
- [perhaps allow a side to fix a price artificially, let everything
- else readjust around it?]
- Sides can specify their trading relationship with other sides,
- by specifying the ratio of tariff to supply [etc].
- [trade relationship is indep of general trust/friendliness]
- [some type of agreements might be intrinsically enforceable, such as
- exchanges between units that cannot attack or capture each other]
- [exchange of material needs to relax fullness rules or be done as
- a sort of prim, else might not be able to trade when full]
-
- Do supply lines, display unit's supplier and maybe supply route.
- Is there an efficient way to handle this?
-
- To do large elev ranges, use bit 14 to indicate which range,
- define a global that gives ratio of ranges. Also need a descriptor
- for text generation.
-
- Add possibility to see all of a side's units if one of them is captured.
-
- Could have a random dungeon digging process that adds to dungeon just
- ahead of player exploration.
-
- Add plagues and famines as random events, impl could add layer to track
- spread, or else use an mtype that is amt of disease, but then larger amts
- of material should be more harmful.
-
- Add weather. Weather is a process operating on per-hex basis, affected
- by terrain type and elevation and maybe region. Affects unit attrition,
- production, movement, combat, etc.
- Weather needs, temp, pressure, humidity, calculates new values of these
- and also has effects on visibility at multiple levels of atmosphere.
- Need to identify effect of each terrain type (and elevation) on each
- of these, also specify the rate at which changes occur.
- Effects on supply.
- Effect on vision, sensing in general.
- Each utype has preferred weather, gradual falloff in effectiveness.
- Add a generic "violence" value that summarizes wind/storm strength,
- relate to unit behavior.
- Use season to get avg temp, perhaps regulate motions as well.
- Should weather/climate be able to adjust terrain if it is off slightly?
- Impl via weather phenomena - overcast/clouds, rain/snow, storms/wind,
- temperature, humidity (compute value of phenomena, then compute phenomena's
- effect on units).
- Attrition increased by storms, also chance of accidents (for each accident
- type).
- Also chances of "random actions"?
- Could make some types of terrain temporarily impassable.
- Display should show fronts, major storms.
- Compute a daily temperature cycle based on number of daylight hours etc.
- Impl sequence should be fixed weather (weather state), random weather,
- seasonal weather, calculated weather.
- Implies that player-visible/settable state layers should be implemented first.
-
- Distinguish "ideal" material level from "max" level, let
- some percentage of material move towards comfortable areas.
-
- Scorekeeper can forbid the saving and restoring of a game, use in
- nonsecure situations.
-
- Add a scorekeeper that looks at side view to decide whether player has
- discovered something that is to be searched for. Should be able to
- require finding a lost city, etc.
-
- Add option to scorekeeper to run on success/failure of an action
- matching given parameters, plus option to run on occurrence of a specified
- events, otherwise scorekeeper runs at either beginning or end of turn.
- Matching includes side and unit.
-
- --AI
-
- Track contacts with other sides on a per-theater basis.
-
- Mplayer should compute which types are mostly likely to be in play
- at present, and at future times. Can look at initial setup, construction
- times, etc, and ignore types that can't possibly appear.
-
- Mplayer should attempt to compute numbers of units and material needed
- to achieve a goal, to some level of confidence, then set "buildup" plans -
- some units explore/patrol etc, then when buildup finished, should plan
- large-scale attack, from several directions if possible. Reserve units
- should hang around transports, but not sit on them unless transport protected.
-
- Use people sides to adjust theather boundaries sometimes. (how?)
-
- If chance to surrender by siege > 5%, compute an ideal frontage, minimizes
- chance of units getting isolated.
-
- Could do formations by reshaping theaters. Units mass on edge, don't go past
- until AI directs an offensive. If offensive successful, AI adds gains to
- theater.
-
- If returning to a moving transport, and transport destination is further away,
- push a "wait" or "rendezvous" task onto transport's queue.
-
- Be able to change theater size and shape as the situation changes,
- let theater develop to optimal size.
-
- For each theater, distinguish
- recent vs older sightings, with exponential backoff (1-2 turns ago,
- 3-5, 6-10, 11-20, etc).
-
- AI should have a chance_to_own_one_of_type(side, side2, u) that the side's
- current estimate of the likelihood of the given side2 owning at least one
- unit of the given type.
-
- Very small theaters should evaporate (how to recognize?).
-
- Need special code to know how to defend bridgeheads, recent captures,
- etc. Reduce theater size or focus on immediate vicinity. Own units
- in "enemy" theater (define) should be defended against the most
- immediate threats. Look around for threats or potential threats.
- Assign best units to deal with threats.
-
- Need better weighting of hit prob vs death prob, also relate to goals,
- so unit with low hit prob will still attack another unit if it can win
- the game by doing so. (implies we need to evaluate importance of goals,
- nearness to achieving them)
-
- Have machine player compute general dependency chains for its strategy.
- For instance, "need miners to produce uranium from mountains
- to build nukes to attack cities".
- Should be "lazily" computed, as needed to achieve basic goals.
- Strategy code works by calculating a plan that consists of steps
- to reach the goals. Plan is sufficiently detailed when side can
- tell each unit what to do, or doctrine has the same effect.
- Not always totally deterministic, how does this work?
-
- Unit type analysis should be based on average outcome, plus worst/best-case
- outcomes if not maybe not expecting enough action to let things average out.
-
- To estimate materials, scan world, for each unit image, add survival
- needs to min est, stockpile - avg operating costs to likely est,
- total storage capacity to max est. Can use actuals for own and allies.
- Similar for terrain and population.
-
- Unit first spotting human enemy should disappear as quickly
- as possible, might escape before human notices. (exploratory plan only)
- Purely exploratory/recon units should generally avoid combat, try to escape
- and stay hidden if possible.
-
- Resign if goals (as derived from scorekeepers) are provably unachievable.
-
- Theaters of < 6 cells should be removed entirely.
-
- Do base construction as 1) moving to construction site, 2) building, and
- 3) carrying to final site. (Must verify that base or parts of base can
- be carried.)
-
- When enemy unit spotted in a zone, decide if unit is part of larger
- group (like a country), what kinds of units might be present (similar,
- sessile, etc).
- If unit is isolated, decide if it is a threat in any way, if so, make
- a goal "enemy gone from x,y" and assign units to work on this goal,
- with types and numbers sufficient to the job. Can borrow from nearby
- theater if not too time-consuming.
- If group, decide importance (home country being most important),
- also assign # units, maybe make theater, track strengths, # units
- enroute, and # still needed.
- Distinguish units that are dangerous alone and ones that are carriers.
-
- Machine player should attempt to infer other sides' strategies.
- Define an "importance" of activities that gets divvied up among
- subcommanders, so overall plans can be set aside temporarily while
- individuals deal with immediate threats.
-
- Machine player code should look for "choke points" that are standard
- routes between important places and around obstacles. Calculate from
- world and utypes, share among all machines (don't use if haven't seen
- yet!).
-
- Write a stdplay.c that is only applicable if game is similar to standard
- game (examine set of types, but still need to doublecheck numbers).
-
- Eventually add code to negotiate for neutrality/ally status.
-
- --Coding
-
- Write statistics as comments when saving a game, and when requested
- by designer.
-
- Be able to save individual properties along with ids to match with units.
-
- Simplify module-writing flags, eliminate need to set two flags ever.
-
- Add option to save a map rotated, at least by 60-deg increments.
- 60 left, 1st hextant formula is y' = x + y, x' = -y, etc.
-
- Use prob_fraction more often, where applicable.
-
- When lots of mallocs being recorded, either maint enough space to
- record all, or else drop/combine smaller totals to make room to
- record the big allocs.
-
- Write dice specs as dice specs, not large numbers.
-
- Use 16-bit indices to an array of pointers to units.
-
- Add a new re-id slot to units, use to hold new id when renumbering.
-
- Allow the use of a proper vararg implementation (ANSI?).
-
- Add a kernel routine notify_all that goes to all players with displays,
- requires ack from all, support voting and timeouts.
- Use in x/xt version for run errors etc.
- (is this really useful?? could be a general multi-player alert
- with voting/ack requirements)
- multi_alert(msg, sides, [minquorum, mintopass], timeout)
- multi_query
- update_multi_query_display
- interface calls ack_multi_query
-
- Define zzz-s-u-n as cache for shortest name (down to 1 char if possible,
- but confusing if only some have one-char names, others are all-but-one
- char of name, etc)
-
- Define a can_occupy(...,exclunit) that indicates room if given other
- unit is *not* counted (since it will be removed shortly, for instance)
-
- Make a bit vector of allowed sides for each type.
-
- Define performance as a sort of ratio to specmarks, so benchmark game is
- known to last 2 minutes on a 100-specmark machine, etc. Use -R 1, only
- "real" games, various mixes of AI, little/no interaction.
-
- Doctrine consists of a list of modifications to a single doctrine object
- that is final answer (no doctrine relationsships). Can always clone a
- doctrine but then is severed from original.
-
- Flush unit->prevunit links if can't find a use for them.
-
- Add general check on parameter bounds as given in *.def (warnings only
- until all values corrected).
-
- Keyword table(s) should be sorted, can do binary search then.
-
- Define foo_text(buf, n, xxx) where n is available space for description,
- return actual length of text in buffer.
- To get strings, define foo_string(xxx), which returns a 0-terminated string.
-
- Test availability of types always, check through code for usages.
-
- For all units on a side, keep sorted by type, keep ptrs to start of each
- type, use to index faster. Could even maintain separate chains for each type.
- Define a for_all_side_units_of_type(side,type,unitvar) iterator.
-
- Implement a convex region finder that works by picking random points as seeds
- and grows out from those. Sides have to be "locked" if entire side can't
- all grow - combo of locked and unlocked sides allows region to become
- parallelogram, triangle, etc.
- How should borders and connections affect generic region finding?
- Grow from random points until about 3/4 of cells in regions, then scan
- down to finish off. (Could leave single points as "their own regions",
- not alloc any region structs.)
-
- General path objects consist of multiple segments, each with start/end
- point and a validity test (that can be done at any time). Also include
- a bit with segment saying "shortest" or just "nonincreasing distance".
- Should be possible for a path to say "impossible" for some segment??
- (consider path that consists of land travel segments plus a sea hop
- that needs a ferry of some sort - path is still valid and useful.)
-
- Regions should
- point to super-regions, not necessarily contained. Include bits for
- caching connectedness, terrain percentages, etc. Add region layer to
- regular map (each hex can only point to one region, multi-stuff must be
- between regions). Need commands to define and display regions.
- Regions never overlap, must subdivide and make subregions be included
- in several super-regions. True for all regions, don't do multiple
- "region layers" (unless significantly more efficient? check stats).
- Add region layer for mplayers that need to explore, add to layer
- as mplayer sees stuff.
-
- Theory of networked Xconq is that all copies synchronize on actions
- and random seeds, then do run_game and get identical results. Each
- program will broadcast its planned actions, then wait until each other
- program indicates that it has sent all that it plans to. When a program
- has received "done" from all others, then it can safely execute.
-
- Can collect interface/kernel requirements by trying to link one without
- the other.
-
- For any routine in the interface that tweaks in the kernel, have to
- siphon it off to the network also. Do via compiling interface with
- augmented calls, so kernel code need not be modified to know about
- networking. On receiving side, input mux includes a decoder that
- invokes kernel routines (note that decoder has to know about calls
- that not all interfaces actually support, since less-powerful
- interface may get kernel-changing messages from more powerful interface).
-
- Come up with a way to prove that mplayer doesn't cheat by looking
- at structs? Could have a have a "sneaker" that is always invisible,
- never attacked unless mplayer cheats.
-
- Add tests involving two communicating skelconqs with preset port
- numbers, use to test networking behavior.
-
- Add a protocol version number etc so that mismatched versions can't
- connect.
-
- Compress material layers by including info about # bits (1,8,16).
-
- Define a "text buffer" object that is variable-size, resizes as needed,
- do all printfs into it.
- To guarantee integrity, program could display checksum or signature to players
- upon startup, so they can agree as to identity of program.
-
- To do play-by-mail games, need to be able to save an optionally encrypted game
- and pass along to next player -
- player info includes some sort of bit indicating
- where to send to. (player-address slot)
- Encrypted game should retain game-module form as plaintext,
- include a "password" slot, then all numbers appearing at "top level" will be
- decrypted, random forms still read normally.
-
- Optimize mapping side and unit ids back to objects themselves. Use hash
- table for units, direct table for sides.
-
- --Interface
-
- Draw some features by using boundaries, of different appearances.
-
- Need a way to indicate relative order of sort keys in list windows.
-
- [Mac] Don't force update or redraw of windows if clicking a button
- has no visible effect (wrong mag for instance).
-
- [Hint] Never draw things that xform to 0 or 1 pixel areas.
-
- Add view option to lists to summarize rather than enumerate.
-
- When in mono, allow choice of small numbers or letters for side, instead of
- emblem.
-
- At high mag powers, draw people emblems near borders of hex instead of in
- middle. (when emblem width < 1/4 cell width)
-
- Don't draw side emblems on borders with terrain that can't have any people
- (sometimes good, sometimes not - how to tell?)
-
- Define a -h <n> that sets up and waits to get pings from human players.
- Like -e <n>. Kernel only has "wait for <n> remote players", cmdline
- does the -h part. -wait <mins> to say how long to wait before going
- ahead, also allows players to get impatient and start anyway.
- Ideally, the startup host gets a window or command interface
- to control the startup process, see who is in, perhaps edit
- display specs.
- All player specs should be able to add "+n" to adjust advantages,
- as in -e 4+2, +2 alone (one mplayer, +2 advantage?)
-
- Define some common part of imf reading and interpretation in kernel
- or a common support lib, extend basic image structs with interface-specific
- detail:
- struct imf { common com; specific icon,... }
- Common includes size ranges and maybe depths.
-
- Some images in imf may be precalced for a hex or other shape,
- need to indicate specially.
-
- Game should be able to spec relative or absolute widths of borders
- and connections.
-
- If multiple conn/bord types, interfaces should draw offset from each
- other.
-
- Should be able to, from cmdline, list available player slots in a remote
- game without actually trying to get in.
-
- (is sort of done now)
- Allow adding a hole or mask to add side emblem to units (plus offset?).
- Specify as (image ... (emblem-space x y w h) ...)
- Also, each image can declare that an emblem is already embedded, as
- ... (has-emblem <emblem-name>)... (would still draw actual emblem if
- it didn't match the embedded one - leave embedded one, may be useful info)
-
- Should be able to parse dates in commands,
- omit parts that are same as current value (such as year).
- Date string function should cache stuff, so not always allocing new
- strings.
- Length of a turn specified as "<n> <unit>" where <unit>
- is known to calendar type.
- Robustify the base date parsing.
-
- Add a text parser etc for specifying units and types. parse_[urt]type,
- parse_unit should be able to recognize ambiguous matches, either return
- # results or report of multiple, be able to process each independently,
- put in dialog, etc. parse_feature to locate geo geatures by name.
-
- Need keywords for images to tie less specific images at smaller
- scales to more detailed ones - "su-85" -> "tank", etc.
-
- Kernel should deliver basic formatting info in help text, let interface
- digest - need line breaks, text fill, tabs/tabstops, emphasis/bold (use
- ^B,^P,^I chars?). Perhaps some way to name a picture and let interface
- fill in actual picture.
-
- Do something in general for reporting destinations, choices are
- raw coords, dir/dist, or a dest name of some sort (unit or region).
- Useful to have optional map scale to report distances in miles etc?
- Examples: "in xxx country" (needs defn of country)
- (define gvar "start-area-name" that gives name?)
- "NE of country" "E of Foo Bar" "in <region>"
- Function is position_desc(buf, side, x, y), where side==NULL means
- do for omniscient side,.
- also define position_desc_relative(buf, side, x, y, x2, y2).
-
- --Library
-
- Change stdunit so that only towns and cities count, not armies? Will
- require better defensive operations.
-
- Skelconq should examine lib.imf directly during setup, report
- on which images were found for the game being loaded.
-
- Collect all old games, do partial translations.
-
- Image tools should be able to study colors and colorized images
- usefully somehow.
-
- Let images refer to colors by name.
-
- Make new world maps that use connections for straits and rivers.
- Distinguish navigable/unnavigable rivers?
- (extra layers should be optional - could do "ifdef river type")
-
- Add notion of named palettes to .imf files, in form
- (palette name color1 color2 ...)
- then images can refer to palette by name and colors by index.
-
- Modify standard game to be more resource-bound, supply used up
- faster, all units must be kept supplied, need to build strings of
- bases to get supplies out to where needed.
-
- Write a ww2-std-pac-42 game.
-
- --Game Ideas
-
- "Quest"
-
- For one player usually, starts out as a vagabond with limited materials.
- Either convert self to higher "rank", or else have improved capability
- via experience points and more equipment (but what would "equipment" be
- good for exactly?).
- Can capture other humans, animals, etc, use as assistants of variable
- loyalty.
- Terrain is standard. Include rivers and roads, with significant effects.
- Units would be various cities/towns/villages, usual (wandering?) monsters.
- Could have a machine-run side that seeks to capture/kill player, like a
- police force or army (or assassins?).
- Have ships for crossing oceans (but need to "buy" somehow, and if in town,
- town should be on coast).
- Include weather/seasons with significant effects.
- Need unit/material as object of quest, perhaps different kinds for
- different games.
-
- (Need to be able to enter/leave neutral places without capturing, but also
- be able to accept surrender - perhaps a notion of "if a place is indifferent
- to your existence, can interact without combat". Extend to hostile places
- that you can sneak in and out of, though at some risk.)
-
- Should predefine all sides(?), but allow multiple adventurers and only one
- monster side - lock this side so players can't take it (but not always?)
-
- To make a game of graduated difficulty, make a long horizontal world, put
- player at one end, goal at other, lots of monsters in middle,
- tougher ones further away. (Monsters should move around a little,
- but not overwhelm player instantly - could make "electric fences" of
- ttypes crossable by player but not monsters, so even fast monsters confined.)
- Would look like a string of sausages - 1600x40 world is approx equiv to
- 40-level dungeon.
- Won't be computed incrementally though, but could schedule creation
- of high-level monsters to be later in game, make a snowball effect where player
- faces huge numbers of monsters if too slow at first.
-
- To make a race game out of this, make a star shape with players at end points
- and goal in middle.
-
- "Medieval Diplomacy" a la Kingmaker
-
- Each player is a lord/lady with coat of arms.
- Few battles, much maneuvering.
- More alliance machinery?
- Need rules/state for varying degrees/types of alliance, could affect
- mutual transport, control, temporary vs permanent gift, etc.
- Can move armies around, raise/lower taxes, manage rebellions, wheel/deal.
- Players have a chance of dying accidentally or of old age.
- Can players be taken prisoner themselves and try to buy their freedom?
- (Because if player is killed, possessions revert to neutral or to ally
- rather than being acquired by capturer.)
-
- (Need primitive for "exchange", theory is that actual individuals arranging
- trade can prevent cheating on the spot, perhaps include a "chance of cheating
- success" plus "attempt-to-cheat-p" that each player can set.)
-
- (Be able to have "materials" like age or heat or poison that are deadly if you
- accumulate too much? would need a excess-death-chance that is like starvation)
-
- "Modern War"
-
- Develop a modern-day military game.
-
- "Today"
-
- An all-out simulation of the modern world at a 1/2 degree scale,
- with each indep country as a side! Double size of earth map, stretch
- slightly further north, add cities and population to account for everybody.
- Would need high-density cities, factories, etc. Don't worry about size of
- game, use it as a test of massive scale.
-
- Should have versions at several levels of detail that share same basic
- concepts.
-
- One version should be like PSL empire in concept.
-
- "Space Empires"
-
- Like Spaceword HO or GB, based on thinly scattered solar systems with
- planets as occupants, ships/cities occs of planets. Deep space move
- very slow (but not less than 1 hex/turn?), but could enter/leave gate
- units more quickly if entry of non-adj unit allowed.
- Solar systems are always-seen, but would need to explore planets more
- carefully (planetary surfaces not plausible tho).
- 1-month turns??
-
- "Corporations"
-
- [could make a game based on corporations that have units that are
- factories etc, should be able to buy and sell them]
-
- [most elaborate might be to allow corporations to coexist with
- countries (what does that mean?)]
-
- --More
-
- At end of a turn, display summary/histogram of action/task/plan types
- and outcomes.
-
- Add option to rotate layer data when saving.
-
- Need a general (all-interface) strategy for guaranteeing image
- consistency on screen.
-
- Should be able to specify a rotation when saving a layer.
-
- Should all probabilities be allowed to have two decimal places?
-
- Decide when sides should be able to look at other units' hp.
-
- Decide if/how country growth and initial strength should interact.
-
- For small-part-of-world areas, define daylight-zone and twilight-zone(?),
- which default to 1/2 and 1/12 respectively.
-
- Be able to expand country borders by building or occupying outside original
- country.
- ut_add_people_chance n%
- ut_add_people_adj_chance n%
-
- To decide about revolt, define:
- u_[indep_]revolt_chance .01n%
- uu_[indep_]surrender-chance .01n%
- uu_surrender_range n
-
- Only certain types of units should be able to have mixed feelings, alloc
- loyalty objects for these. Loyalty objects all consistent size, needed only
- if more than two feelings possible, else use 4-byte slot for values.
-
- Define a "process" object:
- (process <name>
- (agents <unit-type(s)>)
- (automated-rate n1)
- (manual-rate n2) ; + acp to do?
- (inputs <material-types>)
- (outputs ...)
- (catalysts ...)
- (terrain-effects ...)
- )
- Process agent units are optional.
- May want to add "tooling" of units to do a process.
-
- Restrict Lisp syntax knowledge to small part of code, allow translation
- to other languages.
-
- Implement delayed views, where a unit that is out of contact with the side
- keeps own view data and only merges when in contact with side again.
-
- Add an "engineering" plan type, with subtypes "make-access" and "block-access".
- Engineering units build access routes
- by adding/removing/modifying terrain, or by building units that serve
- only as bridges. Should be able to build multi-cell/unit chains in
- difficult cases. Examples: could bridge one blocking cell by a) building
- a transport unit that ferries, or b) building two connections. Could
- bridge a single blocking border by building a connection or by removing
- border. Want to do this for any cell that is very expensive to cross.
- To implement, plan should look for cheapest route assuming that blockage
- has been negated, then build bridges for that route.
- Engineers should also know how to build roads, do that if road movement
- is much faster (such as doubled) than normal movement.
-
- Add a perspective view, of selectable position, direction, and height.
- Easier if only one of six dirs allowed, can't go higher than unit if
- using LOS viewing.
-
- WWII scenario should be able to have a "neutrals" side that resists
- involvement. Attempts to attack neutrals should have some consequences.
-
- Add a type of random event where a side or group of units can change
- to an active side all at once, reflects changing politics, requires
- maintenance of reserves, etc.
-
- To do patrolling/picketing, space units so that few or no holes in coverage.
- In theater being covered, check view dates and send units to update oldest
- information - should be closest unit or one assigned to cover. Could therefore
- have a patrolling unit that only moves very little since its view range covers
- nearly entire assigned area. Allowable age of views depends on what sort of
- surveillance is avail, how many units are assigned.
-
- Derive acceptable risks from goals - unit that is crucial to game should not
- risk self, disposable types can be sacrificed.
-
- For each type of goal in game, decide which units help accomplish and how
- well, which units support indirectly, etc. Also classify by short/long term
- value - short-term is 5-10 turns or 1/10 of game, long-term is length of game.
-
- Set initial theaters to be identical to initial search zones, gradually modify
- to match terrain better. (Theaters divide down middle of seas, etc.)
- Initial search zones should be from center of country in six dirs, subdivided
- by distance (increment should be 10, speed of fastest unit, 1/10 of world).
- Can use knowledge of country size to optimize search, by spacing out explorers,
- not filling in details of terrain until later (is diff, low-priority goal,
- maybe subsumed by patrolling).
-
- Construction calculations should prefer multi-purpose units, but randomize if
- values close together. (Test by making game variants with ultra-powerful
- units, should see mplayer shift to building all the time.)
- Each goal should be characterized timewise, so mplayer can start builds and
- have units ready when goal becomes relevant.
-